On-line web-based services are widely used in today's society, a typical example being on-line banking services. However, problems associated with transaction security have caused serious challenges and risks to institutions and their customers. The increase in identity theft and the resulting financial losses have become major obstacles that institutions have sought to overcome to ensure a secure on-line environment and to maximize the potential benefits and value of on-line services.
In a global economy with billions of transactions carried daily over insecure public Internet Protocol (IP) networks, identity protection becomes paramount. Commerce transactions are based on the trust that each party places in the integrity of the other's credentials. The resultant proliferation of identity systems is forcing individuals to become their own identity administrators.
Organizations are increasingly vulnerable to substantial economic loss from cyber security attacks. In the case of an information security breach, financial institutions in particular can be exposed to a significant financial loss, as well as a loss of reputation. In general, the customer computer environment is considered to be insecure with potential for a variety of malicious software to be inserted, such as keystroke recorder, Trojan horse, or even screen recorder, etc., able to record a customer's keystrokes, redirect critical messages to a fake server, or to effectively “video record” the customer computer's screen (buffer). By using a variety of means, hackers are able to steal customer's identities. Even worse, local sessions can be hijacked and critical data modified.
Current solutions are largely aimed at improving the network communication security aspects (even though the actual network communication links are secure enough—as long as man-in-the-middle attacks and the like are prevented). However, the bigger problem lies in detecting and preventing attacks on communications within the client platform itself.
The shortcomings of the current systems apply to personal computer clients running browsers, as well as to personal hand-held digital assistants, ‘smart-phones’, and like network client devices.
Authentication
The traditional way to authenticate a customer is to provide a user name and password from the customer's client computer. However, this one-factor (e.g. user-id+password) authentication is not secure enough to protect either the customer or the institution from attack by malicious software or malware (including ‘Trojan horses’) using approaches such as man-in-the-middle (MITM), man-in-the-browser (MITB), and keystroke logging.
A man-in-the-middle (MITM) attack is one in which the attacker intercepts messages in a public key exchange and then retransmits them, substituting his own public key for the requested one, so that the two original parties still appear to be communicating with each other.
Man-in-the-browser (MITB) is a security attack where the perpetrator installs a Trojan horse on a victim's computer that is capable of modifying that customer's web commerce transactions as they occur in real time. A man-in-the-browser attack, unlike “phishing”, can occur even when the victim enters the Uniform Resource Locator (URL) into the browser independently, without an external prompt. On the surface, commerce transactions take place normally with expected prompts and password requirements. An MITB attack is more difficult to prevent and disinfect, however, because the activity, instead of occurring in an interchange of messages over the public network, takes place between the customer and the security mechanisms within that customer's browser or client computer.
Two-factor authentication (TFA) is a security process in which the customer provides two means of identification, one of which may be a physical token, such as a card, security token or Universal Serial Bus (USB) device, and the other is typically something memorized, such as a security code. In this context, the two factors involved are sometimes spoken of as “something you have” and “something you know”.
Although TFA improves the authentication security, its implementation tends to lead to a costly system. In many TFA systems today, the verification of both the physical token and the security code are conducted at a remote authentication server. This approach may require separate protocols to authenticate the physical token identifier and the customer security code. Since a centralized authentication server must deal with large volumes of on-line commerce transactions at the same time, this approach also results in scalability issues.
Transaction Authentication Numbers
In addition to the two factor authorization (TFA) systems mentioned earlier, some on-line banking services use a transaction authentication number (TAN). This takes the form of one time passwords (OTP) to authorize financial transactions. The list of TANs is therefore an additional factor. TANs provide another layer of security above and beyond traditional authentication.
An outline of how TANs function The bank creates a set of unique TANs for the customer.
The customer picks up the list from the nearest bank branch. This is deemed to be secure.
The customer receives a password by mail to the customer's home address.
To log on to his/her account, the customer enters a user name and password as normal. This gives access to certain account information but the ability to process transactions is disabled.
To perform a transaction, the customer enters the request and “signs” the transaction by entering an unused TAN. The bank verifies the TAN submitted against the list of TANs they issued to the customer.
The TAN has now been consumed and will not be recognized for any further transactions.
If the TAN list is compromised, the customer may cancel it by notifying the bank.
In some scenarios TANs provide additional security by acting as another form of two-factor authentication. If the physical document containing the TANs is stolen, it will be of little use without the password. On the other hand, if a hacker cracks the customer's password, they cannot process transactions without the TAN.
The risk of compromising a TAN list can be reduced by using algorithms that generate TANs on-the-fly, based on a secret known by the bank and stored in the token or a smartcard inserted into the token
Thus as increased security has become more critical, the customer is faced with increased complexity and the need to remember several procedures, not to mention user names, passwords, and other security codes or PINs, in order to carry out on line transactions, particularly commerce transactions. This has the effect of discouraging potential customers. In some cases, customers compromise the security of their transactions by reusing passwords, or writing them down, or worse, saving them in a file on their computer for ease of recall/reference.
Factors that require to be addressed include:
Customer perception of complexity;
Customer concerns with security;
Merchant reduction of loss by fraud;
Scalability;
Managing the process(es);
Balancing usability with security;
Minimizing impact on customer computing platform;
Minimizing impact on merchant computing platform; and
Migration from existing to new system.
What is needed is a further development of a flexible and simple identity protection and authentication system and method combined with transaction verification ability that could be used across several service providers, and would be able to accommodate complex identity relationships, and provide ways to eliminate or mitigate common security vulnerabilities, at the same time allowing a complex task to appear simpler to the customer, for example by hiding the complexity under a simple GUI.
There is also a need for stronger identity credentials providing better protection from tampering, and enabling safer high-value and sensitive transactions in areas such as health-care, and banking operations.
State of the art email communication is thus heavily burdened by nefarious activities such as SPAMMING, which describes sending unsolicited emails for advertising purposes, PHISHING, which describes spoofing of email sender's identities with the purpose of convincing the recipients to give up personal information such as credentials or banking information.
Current email communication are based on well-defined industry standard protocols recorded in Request For Comment (RFC) 821, 5321 (SMTP), 3501 (IMAP), 1939 (POP3) specifications. To enhance security of email communication, additional RFC specifications such as 6066 (Transport Layer Security) which describes an encrypted channel, and 6125 (X509) which describes Public Key Infrastructures for service identification over TLS have been added to the original descriptions of the Internet mail architecture (5598).
To lower the threat of malicious email communication, machine learning mechanisms such as spam filters have been proposed, which compare the textual contents against a learned database of textual contents known to be connected to malicious email. Such textual inspection is connected to a number of privacy concerns that might prevent application of this method in certain jurisdictions and organizations.
Other approaches to combat malicious email are based on dynamic black listing of email originating domains that have been identified as the source of malicious email.
However, such approaches are connected to a time-lag that allows a significant number of malicious emails to be sent out before the activity is flagged and the blacklisting filter triggers.